Plot meteograms #74
Plot meteograms #74
Conversation
* Adopt more atomic approach Also use marimo for interactive editing * Move notebook to dedicated folder * Remove original script * Add example config * Revert some wrong changes
* Adopt more atomic approach Also use marimo for interactive editing * Move notebook to dedicated folder * add plot rule * Revert some wrong changes * Solve bugs adopt grib * Replace by plot_forecast_frame.py * Rename * Fix number of points cosmo 1e * Remove globe because it doesn't seem right * Add possibility to set region to none for global plots * Review * Update workflow/scripts/src/plotting.py * Simplify code
| init_time=[t.strftime("%Y%m%d%H%M") for t in REFTIMES], | ||
| run_id=collect_all_candidates(), | ||
| param=["2t"], | ||
| sta=["GVE", "KLO", "LUG"], |
There was a problem hiding this comment.
Parameters and stations should probably be added to the config.
There was a problem hiding this comment.
This comment still stands. I suggest to make parameters and stations configurable for the meteogram. Could also do this for the other showcase plots (i.e. use the same parameters).
|
@MicheleCattaneo now using PeakWeather for plotting station observations, see d1ed4da |
Cool! Could that help? |
jonasbhend
left a comment
jonasbhend
left a comment
There was a problem hiding this comment.
Nice work, thanks Daniele. I have a few questions / comments and I suggest we discuss a bit more how we want to shape evalml going forward. To me what is not clear is how we organize the different commands/flavors (experiment and showcase). So far we have:
- experiment: scores and metrics visualized for all forecasts and baselines jointly
- showcase: example forecast visualizations (no observations)
The meteograms in this PR sit somewhere in between as they combine one run with one baseline, and I am not sure this is the best way to go. Instead I see two ways forward:
- Align meteogram with current showcase, i.e. just a meteogram per run / baseline, no comparison (simple implementation)
- Add support for an arbitrary number of runs and baselines in the same multi-panel plot (my favorite, but probably hard(er) to implement)
What do you think: @Louis-Frey @andreaspauling @dnerini @frazane
| init_time=[t.strftime("%Y%m%d%H%M") for t in REFTIMES], | ||
| run_id=collect_all_candidates(), | ||
| param=["2t"], | ||
| sta=["GVE", "KLO", "LUG"], |
There was a problem hiding this comment.
This comment still stands. I suggest to make parameters and stations configurable for the meteogram. Could also do this for the other showcase plots (i.e. use the same parameters).
| """ | ||
|
|
||
|
|
||
| rule download_obs_from_peakweather: |
There was a problem hiding this comment.
Wouldn't it be more future-proof to download obs from OGD?
| baseline_zarr=lambda wc: _use_first_baseline_zarr(wc), | ||
| peakweather_dir=rules.download_obs_from_peakweather.output.peakweather, | ||
| output: | ||
| OUT_ROOT / "showcases/{run_id}/{init_time}/{init_time}_{param}_{sta}.png", |
There was a problem hiding this comment.
Is this a concious decision to produce meteogram plots per run_id? I can see that this ties in nicely with the showcases, but in this case, I would argue we do the meteograms only for an individual run (without a baseline). Otherwise, we should strive to support an arbitrary number of run_ids and baselines in the same (multi-panel) plot.
There was a problem hiding this comment.
To what extent is the model output comparable to station observations? (Effective model resolution vs. point-scale observations, elevation difference, ...). Would a later integration with the MEC make sense?
There was a problem hiding this comment.
I guess for most (all) parameters the MEC doesn't do anything more sophisticated than just nearest-neighbour / representative grid point + altitude correction. But true, maybe at least the constant lapse-rate correction would be useful.
|
Sorry, some misclicks on my side. Still getting used to the interface. @jonasbhend Yes, I agree that your option 2 is more desirable. Maybe we could go with option 1 for the moment and keep option 2 as an upgrade for later? Also, I think that integration with the MEC would make sense at some point, so that we would need to re-factor the code anyway then (?) |
This PR adds support for plotting meteograms within the evaluation framework. It introduces a new plotting pipeline that generates time-series visualizations of station observations and forecast output. The implementation integrates plotting logic with existing workflows and updates dependencies. It also brings in station observations from the PeakWeather dataset for richer observational context.